The present invention relates to improvements in transaction reservation in an integrated satellite business network.
Transaction reservation is one of the methods used in an Integrated Satellite Business Network (ISBN) to transfer data from a remote network interface (or remote port card) to a host network interface (or hub) over a space link via an inroute. The spacelink employs an air communications channel from the remote network interface to an earth orbit satellite, the earth orbit satellite, and another air communications channel from the earth orbit satellite to the host network interface. An inroute is divided into 45 ms intervals called frames, which are divided into slots. The number of slots per frame and the size of each slot depends upon the frequency used to transmit through the inroute. A 128 Kbps inroute has 90 slots, with each slot having 8 bytes. A Demand Assignment Processor (DAP) within the host network interface allocates inroute frame bandwidth to the remote network interface in a continuous group of slots called a burst.
The remote network interface is coupled to a user device, such as a personal computer, a mini computer, or a dumb terminal, which together with the remote network interface is referred to herein as a remote terminal. The host network interface is coupled to a host device such as a mainframe computer, which together with the host network interface is referred to herein as a host terminal.
Transaction reservation operates as follows. The remote terminal, having one or more data packets to transmit to the host terminal, sends a request to the Demand Assignment Processor. This request indicates the amount of bandwidth, i.e., the number of bytes or packet sizes, required by the remote terminal to transmit each of the queued data packets. The transaction request may include up to twelve packet lengths. If additional data packets are queued, bandwidth for them must be separately requested. The Demand Assignment Processor receives the request and allocates the requested bandwidth in a future inroute frame assuming the requested bandwidth is available during the next thirteen frames, which is the number of frames the Demand Assignment Processor looks ahead. If the requested bandwidth is not available within the next thirteen frames, the request is satisfied to the extend possible, and the remainder of the request is disregarded. The remote terminal must re-request bandwidth for which no assignment is made. The Demand Assignment Processor sends a point-to-point message to the remote terminal indicating the inroute frame number and location within the frame that has been assigned to the remote terminal for transmission of the queued data packets. A separate point-to-point message is sent to each remote terminal receiving a transaction reservation assignment.
As mentioned above, typically, the Demand Assignment Processor looks ahead over the next 13 frames, and allocates frames within the 13 frames on a first come first serve basis according to the requests received from the remote terminals. AS also mentioned above, if a remote terminal requests, e.g., ten data packets, which are subsequently assigned to the remote terminal by the Demand Assignment Processor, and another remote terminal also requests ten data packets, only three of the data packets requested by the other remote terminal can be accommodated within the 13 frames of the Demand Assignment Processor's look-ahead. As a result, the Demand Assignment Processor disregards the seven unsatisfied transaction requests and the other remote terminal is forced to re-request bandwidth to transmit the seven of the ten requested packets.
In a mature (fully utilized) Integrated Satellite Business Network environment, the first ten or so frames of the 13 frames within the Demand Assignment Processor's look-ahead will be full. This is because as the 13-frame look-ahead shifts frame-by-frame in time, empty frames are looked at one at a time, and full frames are transmitted one at a time. By the time two or three empty frames have shifted into view, a request for data packets is received, and the Demand Assignment Processor will allocate these two or three available frames. The requesting remote terminal must then re-request any additional bandwidth needed. As a result, groups of packets larger than two or three frames are accommodated in a piece-meal fashion, which increases the control message overhead otherwise needed to send all of the requested packets.
Control messages in an Integrated Satellite Business Network are transmitted during a portion of the inroute frame referred to as the control aloha component. Individual remote terminals on the Integrated Satellite Business Network randomly select a burst within the control aloha component in which to transmit their request when it becomes necessary for them to transmit a control message to the host terminal. As the control message overhead needed to transmit a group of data packets increases, control message traffic increases on the control aloha component.
When two or more remote terminals randomly select the same burst within the control aloha component in which to transmit a control message, neither of these control messages are received by the host terminal, instead resulting in what is referred to herein as a collision. After sending a control message over the control aloha component, remote terminals initiate a timeout period. In the event an acknowledgment of the control message is not received by the remote terminal within the timeout period, the remote terminal assumes that there has been a collision and resends the control message after randomly reselecting a burst within the control aloha component. As can be seen, as the number of control messages to be sent from the remote terminals increases, the likelihood of two or more of the remote terminals randomly selecting the same control aloha burst in which to transmit a control message increases, thus increasing collisions and further increasing traffic in the control aloha component with resent control messages.
Problematically, because in a mature Integrated Satellite Business Network, only two or three packets can be allocated by the Demand Assignment Processor, as described above, the likelihood of a collision on the control aloha portion of the frame becomes increasingly great.
As mentioned above, transaction request messages sent from the remote network interface to the host network interface consist of a string of bytes indicating lengths of the various packets to be sent from a remote network interface to a host network interface. Up to twelve packet lengths can be sent per transaction request sent via control aloha. Slots within the transaction reservation component are assigned to carry the packets, based on the number of slots available within the transaction reservation component, and the packet sizes requested. If the packets to be sent are either too numerous to be assigned, because, e.g., not enough slots remain unassigned to satisfy the request, or because the packets sizes requested will not fit into any remaining slots, the remote network interface must rerequest transaction reservation slots for those packets that cannot be accommodated. Unfortunately, wasted slots may remain unused within the transaction reservation component if none of the packets for which transaction reservations are requested will fit within the unassigned slots remaining within a transaction reservation component.
One limitation on the initial request for transaction reservation slots is that a transaction request message transmitted via control aloha can carry only twelve packet lengths. Thus, only twelve packets can be requested by a remote network interface in a single control aloha transaction request message. When more than twelve packets need to be sent, the remote network interface must either request reservations for the additional packets using an additional control aloha transaction request message, or the remote network interface may signal the host network interface in the control aloha transaction request message that it has additional packets to send. This is done by setting a piggyback request bit within the control aloha transaction request message. In response to this piggyback request bit, the host network interface assigns fifty six bytes (e.g., 7 slots) within the transaction reservation component, in addition to any slots assigned in response to the control aloha transaction request message, for a piggyback transaction request message. The piggyback transaction request message is capable of holding a string of forty-four packet lengths, as opposed to the twelve packet lengths that can be transmitted in the original transaction request message sent via the control aloha. In the event there are still packets to send after those for which slots are requested in the piggyback transaction request message, a piggyback request bit within the piggyback transaction request message signals the host network interface to allocate another fifty-six bytes for another piggyback transaction request message. Slots for such piggyback transaction request messages are always the first slots assigned by the host network, interface before the slots requested, for data packets, so that the piggyback transaction request message can, hopefully, be processed before the packets that follow are all transmitted. Unfortunately, by repeatedly sending piggyback transaction request messages and setting the piggyback request bit, a single remote network interface can effectively "lock up" the entire inroute until all of the packets it has to transmit are sent. If the packets to be sent make up a large, but non-urgent, message, such as a non-urgent data file, more important messages may be delayed due to lock up of the inroute during the transmission of this file.
One parameter that is configured by a network operator in an integrated satellite business network is the Maximum Transaction Size. This parameter defines the largest packet that can be transmitted over the inroute through the transaction reservation component. Typically is desirable that the transaction reservation component be of a size that is evenly divisible by this Maximum Transaction Size, in hopes that many of the packets sent will be of this size. When, for example, sixty slots are allocated to the transaction reservation component, i.e., when there are 480 bytes in the transaction reservation component, the Maximum Transaction Size can be set to 240 bytes. If there are two packets of this size to be transmitted, these packets will fill the entire transaction reservation component, making efficient use of bandwidth. Unfortunately, many of the packets to be sent, including the above-mentioned piggyback transaction request messages, will be smaller than the Maximum Transaction Size, and therefore optimum use of transaction reservation bandwidth will frequently not be achieved.
In heretofore known Integrated Satellite Business Networks, when fast inroutes are utilized, such as 256 Kbps inroutes, the rate with which large multi-packet messages can be transmitted is limited, not only by the availability of slots within the transaction reservation component, but also by the time it takes to request and be assigned slots. For example, when forty-four packets are to be sent on an otherwise unused inroute (having 143 slots in its transaction reservation component), assuming the Maximum Transaction Size is set to 256 bytes and each of the forty-four packets is 256 bytes in length, the transaction reservation components in nine frames will be utilized. However, it takes a period of time equivalent of sixteen frames to request and be assigned these frames. This is because each transaction request takes about seven frames to reach the host terminal, in about one or two frames to be processed by the host terminal and for a transaction assignment to be made, and about seven frames for the transaction assignment to reach the remote terminal. Thus, about sixteen frames for the needed slots to be requested and assigned. Because the initial transaction request made by the remote terminal is limited to requesting twelve packet lengths, even if these twelve packets are immediately allocated slots, there will still be a sixteen frame delay before the next transaction assignment (which will be made in response to a piggyback transaction request) can be made. Thus, if a large amount of data needs to be sent over this fast and otherwise unused inroute, seven out of every sixteen frames will be unused, thus making use of only about fifty-six percent of the inroute's potential maximum transmission rate.